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(54) Managing page activity of web terminals 

(57) A mechanism for dependably tracking network 
activity such as web page activity among terminals 
[104A..104K...104N] such as a group of browsers. The 
terminals retrieve pages [204... 21 4.. .224] from an HTTP 
server [1 52], each of the pages having embedded infor- 
mation [208] such as an applet. In response to the page 
activity (such as loading, unloading or changing data 
[Fig12A, Fig 12B]) performed at a terminal the respec- 
tive applet [124, 126, 128] reports the activity (together 
with the page URL) to a server [1 44] which in turn stores 
it in a database [148]. Synchronization between pages 
at different terminals is provided by appropriate embed- 
ded information, such as a data tracking and synchro- 
nizing applet [126], which identifies activities and for- 
wards details of the activities via the terminal to a track- 
ing server for database storage and transmission to oth- 
er participating terminals as required. A session [Fig.6] 
can be created for an individual terminal or a group of 
terminals and terminal activity information held as part 
of the session information for access as required by oth- 
er terminals in or joining the session, one of the termi- 
nals may be an administrative terminal. 
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Description 

[0001] The present invention relates generally to a 
method and apparatus for coordinating access to Inter- 
net web sites by a group of web browsers that are being 
run at a group of user terminals. 
[0002] It is known that users can retrieve information 
from web sites (network sites) via the Internet. The basic 
model for retrieving information from web sites is user 
initiated information searching. Specifically, a user inter- 
acts with (via a terminal) a web browser to send a re- 
quest to a web site. In response to the request, the web 
server for the web site retrieves the information request- 
ed and sends the web browser the information arranged 
in so called web page (HTML) format. One of the unique 
features of this model is the feature of "hyper-text links" 
embedded in web pages that have been retrieved. This 
feature enables a user in searching for information to 
"navigate 1 ' from one web page to another In order to 
provide services (or assistance) to users (or customers) 
via the Internet, it is desirable to provide a mechanism 
to track activities performed to the web pages among a 
group of browsers. 

[0003] One method of tracking web pages navigated 
is to install a monitoring program at a web site. When a 
terminal sends requests to a web site, the monitoring 
program at the web side collects the URLs(Uniform Re- 
source Locator) for the requested web pages and sends 
the URLs to a server. However, under this method, the 
monitoring program is not always able to monitor the re- 
quests from the terminal, because when the terminal re- 
trieves web pages from its browser cache space or from 
a proxy server, the requests are fulfilled locally and are 
never sent to the web site. As a result, the URLs are not 
accurately tracked. 

[0004] Another method of tracking web pages navi- 
gated is to install a monitoring program together with a 
browser at a terminal. The monitoring program con- 
stantly communicates with the web browser. However a 
monitoring program designed for a web browser manu- 
factured by one vendor is typically not interoperable with 
or portable to another web browser manufactured by an- 
other vendor because browser interface mechanisms 
are proprietary. This results in a user needing a compli- 
cated monitoring program. 

[0005] Therefore, there is a need for a technique to 
provide web page tracking and without requiring knowl- 
edge of the details about the web navigation software. 
Such a technique must operate where web page activity 
of itself does not generate a request to inform a web site 
of the activity. 

[0006] According to the invention there is provided a 
method for managing activities performed to pages at a 
terminal and activities between said terminal and a fur- 
ther terminal, the pages being retrieved from a network 
site, comprising the steps of: 

(a) at said terminal retrieving pages; 



(b) at said terminal performing activities to said pag- 
es retrieved; 

(c) at the network site recording said activities for 
said terminal; 

5 (d) at the further terminal establishing contact with 
said terminal; and 

(e) at the further terminal displaying activities re- 
corded for said terminal. 

10 The invention further provides the managing of page 
synchronization between activities performed either at 
said terminal or said further terminal. The activities may 
include loading a page, unloading a page and changing 
a data field on a page. 

15 [0007] The further terminal may be an administrative 
terminal. 

[0008] The invention provides a method for tracking 
activities with pages requested for loading over a net- 
work by retrieval from a page server at a network site to 
20 an individual terminal by sending information about the 
activities to a page tracking server comprising the steps 
of: 

(g) loading a first page from the page server, the 
25 page being associated with a page locator for indi- 
cating a location of the page in the server, and the 
page containing program information of at least lo- 
cation information for indicating a program; 

(h) loading the program from the server based on 
30 the location information, and executing the pro- 
gram; 

(j) the program monitoring activities with the page; 
and 

(k) the program sending information about the mon- 
35 itored activities to the page tracking server to be 
available for storage therein. The program informa- 
tion may be the actual program. The page locator 
may be URL (Uniform Resource Locator) and the 
program information may be a tag. 

40 

[0009] The invention will now be described by way of 
example with reference to the appended drawings, in 
which: 

45 figure 1 shows a system includes N terminals, a net- 
work, and a web site, in accordance with the present 
invention; 

figure 2 shows a situation where each of the N ter- 
minals has downloaded its respective Master Ap- 
se plets, DTS Applets, and SessionID Applet, in ac- 
cordance with the present invention; 
figure 3 shows the process the (consumer) Master 
Applet, DTS Applets, and SessionID Applet being 
downloaded into a terminal, in accordance with the 
55 present invention; 

figure 4 shows the process the (consumer) Master 
Applet, DTS Applets, and SessionID Applet being 
invoked, in response to loading a subsequent web 
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page, to perform the operations in accordance with 
the present invention, when these Applets have 
been previously downloaded and cached in a 'ter- 
minal; 

figure 5 shows the process of the (consumer) Mas- . 5 
ter Applet, DTS Applets, and SessionID Applet be- 
ing invoked, in response to loading a subsequent 
web page, to perform the operations in accordance 
with the present invention, when both these Applets 
and the web page have been previously download- io 
ed and cached in a terminal; 
figure 6 shows a session table in greater detail, in 
accordance with the present invention; 
figure 7 shows how an agent (or supervisor) can 
create a session interface by downloading an agent *s 
page (or a supervisor page) from administration 
page repository 1 49, in accordance with the present 
invention. 

figure 8A shows an agent session interface, in ac- 
cordance with the present invention; 20 
figure 8B shows a browser supervisor session in- 
terface, in accordance with the current invention; 
figure 8C shows a supervisor agent session inter- 
face, in accordance with the present invention; 
figure 9 shows a flowchart illustrating the operation 2S 
of joining a session by an agent, in accordance with 
the present invention; 

figure 10 shows a screen display containing two 
browse instances, in accordance with the present 
invention; so 
figure 11 shows a flowchart illustrating the operation 
of web page synchronization, in accordance with 
the present invention; 

figure 12A shows a web page containing five data 
fields, in accordance with the present invention. 35 
figure 12B shows a web page that is similar to that 
of figure 1 2A, except that the data in one of the five 
data fields is changed, in accordance with the 
present invention; . 

figure 1 3 shows a flowchart illustrating the operation *o 
of data synchronization, in accordance with the 
present invention; 

figure 1 4 shows a flowchart illustrating the operation 
of web page tracking, in accordance with the 
present invention; 4 & 
figure 1 5 shows a flowchart illustrating the operation 
of data tracking, in accordance with the present in- 
vention; 

figure 1 6 shows a flowchart illustrating the operation 
of joining a session by a supervisor, in accordance 50 
with the present invention, 
figure 17, there shows three browser instances for 
a supervisor, in accordance with the present inven- 
tion; 

figure 1 8 shows a flowchart illustrating the operation 55 
of re-browsing a web page previously viewed in a 
session, in accordance with the present invention; 
and 



figure 1 9 shows a flowchart illustrating the operation 
of re-browsing all web pages previously viewed in 
a session, in accordance with the present invention. 

Detailed Description of the Preferred Embodiments 

[0010] The following description is presented to ena- 
ble any person skilled in the art to make and use the 
invention, and is provided in the context of a particular 
application and its requirements. Various modifications 
to the preferred embodiment(s) will be readily apparent 
to those skilled in the art, and the principles defined 
herein may be applied to other embodiments and appli- 
cations without departing from the spirit and scope of 
the invention. Thus, the present invention is not intend- 
ed to be limited to the embodiment(s) shown, but is to 
be accorded with the broadest scope consistent with the 
principles and features disclosed herein. 
[0011] Referring to figure 1 , there is shown an exem- 
plary web page synchronization system 100, in accord- 
ance with the present invention. 
[0012] As shown in figure 1, the system includes N 
terminals (104A, I, 104K, i, and 104N), a network 129 
(the Internet, or a combination of the Internet and an 
Intranet), and a web site 1 34. Each of the terminals has 
a telephone set (102A, 1,. 102K, 8, or 102N) installed 
in its vicinity. Each of the terminals can be a PC compu- 
ter, a workstation, a Java station, or even a web TV sys- 
tem. 

[0013] Web site 134 includes a WTS (Web Tracking 
and Synching) gateway 142, a WTS server 144 contain- 
ing a session table 145 and a user class table 147, a 
database processing application 148, an HTTP (Hyper 
Text Transfer Protocol) server 152, and a hard disk unit 
154 for storing consumer page repository 146, admin- 
istration page repository 149, and database 156. All the 
components in web site 1 34 can be installed in one or 
more computer systems. Each of the computer systems 
includes a processing unit (which may include a plurality 
of processors), a memory device, and a disk unit (which 
may include a plurality of disk sets)-. 
[0014] Each of the terminals (104A, I, 104K, i, or 
104N) includes a processor unit (not shown) and a 
memory area (115A, , 115K, , 11 5N), and runs a Java 
enabled web browser (11 4A, 1.114K, l,or114N). Each 
of the memory area (115A, 8, 115K, I, or 11 5N) is main- 
tained by its respective browser (114A, 8, 114K, I, or 
114N). Via network 129, each of the browsers (114A, I, 
1 1 4K, .. , or 1 1 4N) is able to send requests to and receive 
web pages from HTTP server 152, and to display the 
web pages received at its respective terminal. Each of 
the browsers (11 4A, 8, 114K, 8,or '114N) is able to run 
a Master Applet (124A, 8, 124K, I, or 124N), a set of 
DTS (Data Tracking and Synching) Applets, a Session- 
ID Applet, and an Agent Applet. As shown in figure 1, 
these Applets are stored in consumer page repository 
146 and can be downloaded from consumer page re- 
pository 146 and stored in the memory areas of the ter- 
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minals (104A, I, 104K, i, 104N). 
[0015] Referring to figure 2, there is shown the situa- 
tion where each of the terminals (104A, I, 104K, I, or 
104N) has downloaded its respective Master Applets 
(124A, 1, 124K, I, or 124N), DTS Applets (126A, I, 
126K, 1, or 128N), and SessionID Applet (12BA, 8, 
128K, I, 128N), in accordance with the present inven- 
tion. 

[0016] In figure 2, each of the (consumer) Master Ap- 
plet (1 24A, 1, 124K, 1, or 124N) is primarily responsible 
for: (1) in response to loading each web page at its re- 
spective browser, opening a dedicated socket, and es- 
tablishing a socket connection to WTS gateway 142 via 
network 129 for its respective browser (114A, i, 114K, 
§, 114N), (2) communicating with WTS server 144 via 
the socket connection, from which WTS server 144 is 
able identify the origin (i.e. which browser, which web 
page, etc.) of the commands and information that are 
being delivered through, (3) monitoring the activities of 
its respective browser, (4) sending the information about 
its respective browser's activities to WTS server 1 44, (5) 
receiving and processing the information about other 
browsers' activities, (6) via the socket connection, pro- 
viding a single communication path to WTS server 144 
for DTS Applets (126 A, 1.126K, 1, or 126N), SessionID 
Applets (128A, I, 128K, I, or 128N), or any other con- 
sumer Applets embedded on the same page with the 
Master Applet, (7) sending commands to WTS server 
1 44 to request services, for itself and for DTS Applets 
(126A, 8, 126K, 1, or 126N), SessionID Applets (128A, 
I, 128K, 1, or 12BN) , or any other consumer Applets 
embedded on the same page with the Master Applet, 
and (8) sending user class information together with the 
commands, to indicate that its respective browser is a 
consumer user. 

[0017] Each set of DTS Applets (126A, I, 126K, I, 
or 126N) contains one or more individual DTS Applets, 
which are primarily responsible for: (1 ) displaying and 
monitoring the data activities (data inputs or data up- 
dates of data fields) on web pages that are being dis- 
played by its respective browser, (2) sending the data 
activities to WTS server 144 via its respective Master 
Applet, (3) receiving the data activities from other brows- 
ers via its respective Master Applet, and (4) processing 
the data activities from other browsers for the web pages 
that are being displayed by its respective browser. 
[0018] Each of the SessionID Applets (128A, 1, 
128K, I, or 128N) is responsible for retrieving, and for 
displaying on a web page the current SessionID. 
[0019] As shown in administration page repository 
149, Agent Applet (or Supervisor Applet) is responsible 
for creating a session interface, joining, monitoring, and 
controlling a session through the session interface. The 
(administration) Master Applet is primarily responsible 
for: (1 ) opening a dedicated socket, and establishing a 
socket connection to WTS gateway 1 42 via network 1 29 
for the session interface created by Agent Applet, Su- 
pervisor Applet, or any other administration Applets em- 



bedded on the same web page with the Master Applet, 

(2) communicating with WTS server 144 via the socket 
connection, from which WTS server 144 is able identify 
the origin (i.e. from which session interface) of the com- 

5 mands and information that are being delivered through, 

(3) via the socket connection, providing a single com- 
munication path to WTS server 144 for Agent Applet, 
Supervisor Applet, or any other administration Applets 
embedded on the same web page with the Master Ap- 

io plet, and (4) sending user class information together 
with the commands, to indicate that its respective 
browser is an administration user. 
[0020] WTS gateway 1 42 is responsible for maintain- 
ing all socket connections between Master Applets and 

J5 WTS server 144. The connections between Master Ap- 
plets and WTS gateway 142 take place using standard 
sockets. The connection between WTS gateway 142 
and WTS server 144 takes place using RMI (Remote 
Method Invocation). 

20 [0021] WTS server 144 is responsible for: (1) manag- 
ing and tracking the activities of all browsers participat- 
ing in active sessions, exemplary activities including: 
loading of, interacting with, and unloading of web pages, 
(2) recording the information about the activities, (3) 

2S managing the synchronization of the activities for all 
browsers participating in the active sessions, (4) creat- 
ing a session when a consumer user (via a browser) 
sends a request to web site 1 34 for the first time, (5) 
defining the session length intervals, (6) purging ses- 

30 sions that have been inactive for more than the specified 
session length intervals, (7) adding and deleting partic- 
ipants to a session, and (8) providing services to all com- 
mands from consumer Applets, such as: (consumer) 
Master Applet, DTS Applets, SessionID Applets, and 

3S administration Applets, such as: (administration) Master 
Applet, Agent Applets, and Supervisor Applet. 
[0022] Consumer page repository 1 46 stores the web 
pages and Applets for consumers. Consumer Applets 
can be selectively embedded into consumer web pages. 

40 Exemplary consumer Applets include: (consumer) Mas- 
ter Applet, DTS Applets, SessionID Applet, etc. 
[0023] Administration page repository 149 stores the 
web pages and Applets for call center administration us- 
ers, including: administrator, supervisor, agent, etc. Ad- 

45 ministration Applets can be selectively embedded into 
administration web pages. Exemplary administration 
Applets include: 

(administration) Master Applet, Agent Applet, Supervi- 
sor Applet, etc. 

so [0024] To better describe the present invention, the 
Applets stored iri (or downloaded from) repository 146 
can be referred to as consumer Applets, and the Applets 
stored in (or downloaded from) repository 149 can be 
referred to as administration Applets. For example, the 

ss Master Applet stored in (or downloaded from) repository 
146 can be referred to as consumer Master Applet, and 
the Master Applet stored in (or downloaded from) repos- 
itory 149 can be referred to as administration Master Ap- 
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plets. HTTP server 152 contains a security application 
that allows consumer users to get access only to the 
web pages stored in consumer page repository 1 46, and 
allows administration users (such as administrator, su- 
pervisor, agent, etc.) to get access to the web pages 
stored in both consumer page repository 146 and ad- 
ministration page repository 149. 
[0025] Session table 1 45 is responsible for maintain- 
ing the information for ail active sessions. 
[0026] Class table 147 is responsible for keeping 
records of user classes assigned to different users. List- 
ed are exemplary user classes: administrator, supervi- 
sor, agent, and consumer. 

[0027] Based on user classes (administrator, super- 
visor, agent, and consumer), WTS server 144 provides 
the following services: 

(1 ) creating a session (consumer); 

(2) storing data received from a session participant 
(supervisor, agent, and consumer); 

(3) listing active sessions (administrator and super- 
visor); 

(4) listing the information associated with active 
sessions (administrator, and supervisor); 

(5) listing current users (administrator); 

(6) joining a session (supervisor and agent); 

(7) terminating a session (supervisor); 

(8) monitoring a session (supervisor and agent); 

(9) configuring a session parameters (administra- 
tor); and 

(10) sending commands and information to a con- 
sumer Master Applet or an administration Master 
Applet in a participating browser (supervisor, agent, 
and consumer). 

[0028] Database 156 is responsible for storing data 
collected in session table 1 45. 

[0029] HTTP server 1 52 is responsible for processing 
the requests issued by one of the web browsers, retriev- 
ing the web pages from either consumer page repository 
146 or administration page repository 149, and sending 
the web pages to the browsers that have generated 
these requests. 

[0030] Database processing application 148 is re- 
sponsible for writing the data collected in session table 
145 into database 156. 

[0031] Referring to figure 3, there is shown the proc- 
ess of how the (consumer) Master Applet, DTS Applets, 
and SessionlD Applet being downloaded into terminal 
104Afrom HTTP server 152 in response to loading an 
initial web page, and then being invoked to perform the 
operations in accordance with the present invention. 
[0032] As shown in figure 3, a (consumer) Master Ap- 
plet, a set of DTS Applets, and a SessionlD Applet are 
embedded into web page 204 by using a set of applet 
tags 208. Web page 204 is associated with a specific 
URL indicating the location of web page 204 in HTTP 
server 152. 



[0033] As indicated by dotted line (1), web browser 
114A sends a request including the URL of web page 
204 to HTTP server 152 via network 129. As indicated 
by dotted line (2), in response to the request, HTTP serv- 

5 er 1 52 retrieves web page 204 from consumer page re- 
pository 146 and sends it to web browser 114A via net- 
work 129. Web page 204 contains a set of applet tags 
208, which indicate the location of Master Applet, DTS 
Applets, and SessionlD Applet in HTTP server 152. As 

10 indicated by dotted line (3), web browser 114A loads 
web page 204. As indicated by dotted line (4), since 
Master Applet, DTS Applets, and SessionlD Applet 
have not been downloaded, web browser 114A sends 
requests via network 129, to download these Applets 

75 based on applet tags 208. As indicated by dotted line 
(5), HTTP server 152 sends Master Applet, DTS Ap- 
plets, and SessionlD Applet to browser 11 4A via net- 
work 129. As indicated by dotted line (6>, browser 114A 
stores Master Applet 124A, DTS Applets 126A, and 

20 SessionlD Applet 128A into memory area 115A of ter- 
minal 104A, and initializes and invokes these Applets. 
After being invoked, these Applets are running together 
with web browser 114A, to monitor and process the ac- 
tivities for which they are assigned to be responsible. As 

25 indicated by line (7), Master Applet 124A opens a ded- 
icated socket and establishes a socket connection to 
WTS gateway 1 42 for browser 11 4A and web page 204. 
via the socket connection, Master Applet 126 sends 
WTS server 1 44 a command, together with an I D unique 

30 to browser 114A. In response to the command from 
Master Applet 126, WTS server T44 creates a session 
for browser 114A based on the unique ID, and issues a 
time stamp (loading time) indicating the time at which 
the command was received, and stores the URL and 

35 time stamp of web page 204 into the session created for 
browser 114. As will see in the description in connection 
with figure 6 following, the URL, command, and loading 
time are stored in a URL history list and a command list 
created for the session. 

40 [0034] Referring to figure 4, there is shown the proc- 
ess of the (consumer) Master Applet 124A, DTS Applets 
126A, and SessionlD Applet 128A being invoked, in re- 
sponse to loading a subsequent web page 214 (subse- 
quent to web page 204), to perform the operations in 

45 accordance with the present invention, when these Ap- 
plets have been previously downloaded and cached in 
terminal 1 04 A. 

[0035] As indicated by dotted line (1), to download 
web page 214, web browser 114A sends a request in- 

50 eluding the URL of web page 214 to HTTP server 152 
via network 129. Before loading web page 214, the fol- 
lowing events occur: (a) browser 114A instructs Master 
Applet 1 24A to run a stop routine, (b) via the socket con- 
nection established for browser 114A and web page 

55 204, Master Applet 124A sends a command to inform 
WTS server 1 44 that web page 204 has been unloaded, 
and disconnects the socket connection established for 
browser 114A and web page 204, (c) WTS server 144 
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issues a time stamp (unloading time) indicating the time 
the command was received, and (d) records the URL 
and the time stamp of web page 204 into the session 
created for browser 1 14A. As will be seen in the descrip- 
tion in connection with figure 6, following, URL, com- 5 
mand, and unloading time are stored in a URL history 
list and a command list created for the session. As indi- 
cated by dotted line (2), HTTP server 1 52 retrieves web 
page 214 from consumer page repository 146 and 
sends it to browser 11 4A. Like web page 204, web page io 
214 contains a set of applet tags 208 for indicating the 
location of Master Applet 124A, DTS Applets 126A, and 
SessionID Applet 128A. As indicated by dotted line (3), 
web browser 11 4A loads web page 214. As indicated by 
dotted line (4), in response to the loading of web page *5 
214, web browser 114A locates Master Applet 124A, 
DTS Applets 126A, and SessionID Applet 128A (based 
on the indication of applet tags 208) that are cached by 
browser 114A in memory area 115A, and initializes 
these Applets and then invokes them. As indicated by 
line (5), Master Applet 124A opens a dedicated socket 
and establishes a socket connection to WTS gateway 
1 42 for browser 1 1 4A and web page 21 4. Via the socket 
connection established for browser 11 4A and web page 
214, Master Applet 126A sends a command, together 
with the ID unique to browser 114A and the URL of web 
page 21 4, to inform WTS server 1 44 that web page 2 1 4 
has been loaded. WTS server 144 issues a time stamp 
(loading time) indicating the time the command was re- 
ceived and stores the URL and time stamp of web page 
into the session created for browser 11 4A. As will be 
seen in the description in connection with figure 6, fol- 
lowing, URL, command, and loading time are stored in 
a URL history list and a command list created for the 
session. 

[0036] Referring to figure 5, there is shown the proc- 
ess of the (consumer) Master Applet 1 24A, DTS Applets 
126 A, and Sessionl D Applet 128A being invoked, in re- 
sponse to loading a subsequent web page 224 (subse- 
quent to web page 214), to perform the operations in 
accordance with the present invention, when both these 
Applets and web page 224 have been previously down- 
loaded and cached by browser 114A in terminal 104A. 
[0037] As indicated by dotted line (1>, web browser 
114A loads web page 224 cached in memory area 11 5 A 
maintained by browser 114A. Like web pages 204 and 
214, web page 224 contains a set of applet tags 208 
indicating the location of Master Applet 124A, DTS Ap- 
plets 126A, and SessionID Applet 128A. Before loading 
web page 224, the following events occur: (a) browser 
1 1 4A instructs Master Applet 1 24A to run a stop routine, 
(b) via the socket connection established for browser 
1 1 4A and web page 21 4A, Master Applet 1 24A sends a 
command to inform WTS server 1 44 that web page 21 4 
has been unloaded, and disconnects the socket con- 
nection established for browser 114A and web page 
21 4, (c) WTS server 1 44 issues a time stamp (unloading 
time) indicating the time the command was received, 



and (d) WTS server 144 records the URL and time 
stamp of web page 214 into the session created for 
browser 114A. As will be seen in the description in con- 
nection with figure 6, following, the URL, command, and 
unloading time are stored in a URL history list and a 
command list created for the session. As indicated by 
dotted line (2), in response to the loading of web page 
224, browser 114A locates Master Applet 124A, DTS 
Applets 126A, SessionID Applet 128A that have been 
cached by browser 1 1 4A in memory area 11 5A in termi- 
nal 104A, and initializes and invokes these Applets. As 
indicated by line (3), Master Applet 124A opens a ded- 
icated socket and establishes a socket connection to 
WTS gateway 1 42 for browser 1 1 4A and web page 224. 
Via the socket connection established for browser 114A 
and web page 224, Master Applet 126A sends a com- 
mand, together with the ID unique to browser 11 4A and 
the URL of web page 224, to inform WTS server 144 
that web page 224 has been loaded. WTS server 144 
issues a time stamp (loading time) indicating the time 
the command was received and stores the URL and 
time stamp into the session created for browser 1 1 4. As 
will be seen in the description in connection with figure 
6, following, the URL, command, and loading time are 
stored in a URL history list and a command list created 
for the session. 

[0038] In the example shown in figure 5, it should be 
appreciated that even through no request arrives at HT- 
TP server 144 when web page 224 is loaded from 
cached memory in terminal 104A, Master Applet 124A 
still sends browsing activities to WTS server 144. 
[0039] It should be noted that the processes shown in 
figures 3-5 of loading and invoking Master Applet, DTS 
Applets, and SessionID Applet forterminal 104Acan al- 
so be used for terminals 104K, I, 104N. 
[0040] In figures 3-5, Master Applet, DTS Applets, 
and SessionID Applet are all embedded into web pages 
204, 214, and 224. However, it should be noted that not 
all the Applets are required to be embedded into a web 
page. Depending on the desired functions to be per- 
formed, respective Applets can be selectively embed- 
ded into a web page by selectively setting applet tags 
in the web page. For example, if data synchronization 
and tracking of individual elements are not needed, the 
applet tags for linking DTS Applets can be eliminated 
from the web page. By the same token, if additional func- 
tions are needed, additional applet tags can be added 
into the web page to link additional Applets. 
[0041] Referring to figure 6, there is shown session 
table 145 (see figure 1) in greater detail, in accordance 
with the present invention. 

[0042] While browsers at their respective terminals 
are browsing through the web pages in web site 134, 
WTS server 144 collects and analyzes the information 
about the interactions between all browsers and the web 
pages that have been downloaded to the browsers from 
web site 134. One difficulty in collecting and analyzing 
such information is that browsing individual web pages 
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in web site 1 34 is a stateless process. More specifically, 
web site 1 34 receives a sequence of requests from dif- 
ferent browsers, and sends the respective web pages 
to the respective browsers in response to the sequence 
requests. Since in processing the requests from an in- 
dividual browser, web site 1 34 does maintain a constant 
connection to the same browser to keep an one-to-one 
relationship, web site 134 has no control over, or main- 
tain data on, the sequences of the requests from the 
browsers. 

[0043] To meaningfully collect and analyze the infor- 
mation about the interactions between the browsers and 
web pages, a session is defined as a collection of web 
page interactions that occur over a given period of time 
from a specific browser. A session is created when a 
browser first hits web site 134, and a session window 
(or session length interval) is defined for the session. If 
activities from a specific browser (identified by an ID 
unique to the browser, issued by a respective Master 
Applet) does not occur within the session window, the 
session is terminated and cleaned up by WTS server 
144. A session window is refreshed (reset to time zero) 
each time the information about the associated browser 
is sent to WTS server 144. For example, if a session 
window is defined as 15 minutes, as long as the asso- 
ciated terminal has some activity every 15 minutes, the 
session will remain open. After 15 minutes of inactivity, 
the session is terminated and purged. A subsequent re- 
quest from the same terminal will cause a new session 
to be created. After a session has been created for a 
terminal, one or more other terminals can join the ses- 
sion. 

[0044] As shown in figure 6, session table 145 in- 
cludes M Session IDs created for M sessions respec- 
tively. Each of the session ID is associated with: (1) a 
session list for maintaining information about a session, 
(2) a participant list for maintaining information about all 
participant browsers in a session (note: when a session 
is first created, it only contains one participant), (3) a 
URL history list for maintaining information about all web 
pages visited by all participants in a session, (4) a data 
list for maintaining information about the data fields on 
the web pages visited by ail participants in a session, 
and (5) a command list for maintaining information about 
all commands issued to WTS server 1 44 by the various 
participants in a session. 

[0045] Typical items in a session list are: (1 ) Sessio- 
nlD for identifying a session, (2) UserName for indicat- 
ing the actual name for whom the session is created, (3) 
StartTime for indicating the time of starting the session, 
(4) StopTime for indicating the time of stopping the ses- 
sion, and (5) SessionNotes for recording the notes of 
the session. 

[0046] Typical fields contained in a participant list are: 

(1 ) Sessionl D for linking the participant list to a session, 

(2) ParticipantID for identifying a participant, (3) Partic- 
ipant Addresses for indicating a participant's IP address, 
(4) Class for indicating the user class of the participant 



(customer, agent, supervisor, administrator, etc.) and (5) 
Direction for indicating the synchronization direction for 
the participant browser. 

[0047] Typical fields contained in a URL history list 
5 are: (1) SessionID for linking the URL history list to a 
session, (2) PageURL for indicating the URL of a web 
page visited, (3) ParticipantID for identifying a partici- 
pant who visited the web page, (4) LoadingTime for in- 
dicating the loading time of the web page, and (4) Un- 
10 loadingTime for indicating the unloading time of the web 
page. 

[0048] Typical fields contained in a data list are: (.1 ) 
SessionID for linking the data list to a session, (2) Was- 
Relayed for indicating if this data field has been broad- 

15 casted, (2) FieldName for indicating the actual name of 
the datafield, (3) DataName for indicating the name of 
the data field displayed on a web page, (4) Datavalue 
for indicating the value of the data field, (5) TimeStamp 
for indicating the time at which this datafield is updated, 

20 (6) URL for indicating the web page on which the data 
field was displayed, and (7) ParticipantID for indicating 
the participant browser who updated this data field. 
[0049] Typical fields contained in a command list are: 
(1) SessionID for linking the data list to a session, (2) 

25 Command for indicating the specific command execut- 
ed (loading a page, unloading a page, changing a data 
field, etc.), (3) URL for indicating the web page to which 
the command operated, (4) FieldPoint for indicating the 
data field to which the command operated, and (5) 

30 TimeStamp for indicating the time at which command 
was executed. 

[0050] Before a session is purged from session table 
145, database processing application 147 stores the as- 
sociated session list, URL history list, and command list 
35 to database 1 56. The data contained in these three lists 
can be later used by data warehouse integration appli- 
cations. 

[0051] Referring to figure 7, there is shown an opera- 
tion for creating a session interface for an agent (or a 

40 supervisor) by downloading an agent page (or a super- 
visor page) from administration page repository 149, in 
accordance with the present invention. In the example 
shown in figure 7, it is assumed that administration user 
class (either agent user class or supervisor user class ) 

45 j s assigned to terminal 1 04N, so that the security appli- 
cation in HTTP server 1 52 grants the access to the web 
page stored in both consumer page repository 146 and 
administration page repository 149. 
[0052] At step 702, an agent at terminal 104N types 

50 in an agent URL at terminal 104N, and browser 114N 
sends the URL to HTTP server 1 52, to retrieve an agent 
page, in which an (administration) Master Applet and an 
Agent Applet are embedded. For a supervisor, he/she 
types in a supervisor URL at terminal 1 04N, and browser 

55 114N sends the URL to HTTP server 152, to retrieve a 
supervisor page, in which an (administration) Master 
Applet and a Supervisor Applet are embedded. 
[0053] At step 704, HTTP server 152 retrieves the 
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agent page (or a supervisor page) from administration 
page repository 149 and sends it to browser 114N. 
[0054] At step 706, browser 114N downloads the 
agent page, in which a Master Applet (administration 
Master Applet) and an Agent Applet are embedded; or s 
downloads the supervisor page, in which a Master Ap- 
plet (administration Master Applet) and a Supervisor Ap- 
plet are embedded. 

[0055] At step 708, browser 114N downloads the 
Master Applet and Agent Applet from HTTP server 1 52, 1 o 
initializes and invokes these Applets; or downloads the 
Master Applet and Supervisor Applet from HTTP server 
152, initializes and invokes these Applets. 
[0056] At step 71 0, Master Applet opens a dedicated 
socket, establishes a socket connection to WTS gate- *5 
way 142, and sends an ID unique to browser 114N to 
WTS server 144. WTS server 144 is able to identify 
browser 114N based on the unique ID. 
[0057] At step 712, Agent Applet creates an agent 
session interface 800A shown in figure 8A for the agent 
user; or Supervisor Applet creates a supervisor session 
interface 800B shown in figure 8B for the supervisor 
agent. 

[0058] Referring to figure 8A, there is shown an agent 
session interface 800A created for an agent at step 71 2, 
in accordance with the present invention. 
[0059] As shown in figure 8A, the session interface 
contains a text box 804 for entering a session ID, a Join 
session button 806 for joining a session identified by the 
session ID, a drop button 808 for leaving a session, a 
leader check box 810 (selecting of which designates a 
browser as a leading browser in synchronization), a fol- 
lower check box 812 (selecting of which designates a 
browser as a following browser in synchronization), a 
scrollable list box 81 6 for displaying the information con- 
tained in the participant list associated with a selected 
session, a scrollable list box 818 for displaying the in- 
formation in an identified URL history list, and a text box 
820 for displaying the information in an identified data 
list. If both the leader and follower check boxes 81 0 and 
81 2 are selected in the agent session interface, browser 
1 1 4 A acts as both leading and following browser in syn- 
chronization. 

[0060] Referring to figure 8B, there is shown a brows- 
er supervisor session interface 800B created for a su- 
pervisor at step 712, in accordance with the current in- 
vention. 

[0061] As shown in figure 8B, the session interface 
contains a scrollable list box 832 for displaying session 
IDs of all active sessions in session table 145 and for 
selecting one of the session IDs, a text box 834 for dis- 
playing relevant statistics of WTS server 1 44, a multi col- 
umn scrollable list box 836 for displaying details about 
the session selected in scrollable list box 832, a select 
session button 838 for selecting a session from scrolla- 
ble list box 832. By using the information in scrollable 
list box 832, a supervisor agent can monitor all active 
sessions. By using the information in multi column scrol- 



lable list box 836, a supervisor can monitor operational 
status of a session selected from scrollable list box 832, 
including: (1 ) whether this session is being helped by an 
agent, (2) user name, and (3) agent ID. By selecting se- 
lect session button 838, a supervisor can create an 
agent session interface as shown in figure 8C. 
[0062] Referring to figure 8C, there is shown a super- 
visor agent session interface 800C, in accordance with 
the present invention. 

[0063] Referring to figure 9, there is shown a flowchart 
illustrating the operation of joining a session by an 
agent, in accordance with the present invention. 
[0064] In the example shown in figure 9, it is assumed 
that: (1) a consumer at terminal 104A is browsing web 
pages from consumer page repository 146 via browser 
114A, (2) session list 1 shown in figure 6 has been cre- 
ated for browser 11 4A, (3> an agent class has been as- 
signed to browser 114N, (4) agent session interface 
800A shown in figure 8A has been displayed on terminal 
104N; (5) a (administration) Master Applet and Agent 
Applet have been previously downloaded into browser 
114N, (6)- a dedicated socket connection has been es- 
tablished for session interface 800A displayed at termi- 
nal 104N by the (administration) Master Applet, and (7) 
the agent at terminal 104A is on duty at a call center. 
[0065] As shown in figure 9, at step 902, the consumer 
is browsing a web page at terminal 104 A. On the web 
page, SessionID Applet 128A displays the current ses- 
sion ID. A call center telephone number the consumer 
can call is also displayed on the web page. 
[0066] At step 904, the consumer is connected to the 
call center by dialing the telephone number via tele- 
phone 102A (see figure 1), and the call is directed by 
the call center to the agent. 

[0067] At step 906, the consumer tells, via telephone 
102A (see figure 1), the agent the current session ID 
displayed. It should be noted that, instead of using the 
telephone, the agent can be informed of the current ses- 
sion ID by alternative methods. For example, the con- 
sumer can enter his/her telephone number into a special 
web page that contains the caller ID of the consumer 
along with the current session ID. This information can 
be stored into a special lookup table that can be used 
by the agent to lookup the current session ID. 
[0068] At step 908, at terminal 1 04N, the agent types 
the current session ID into text box 804 (see figure 8A). 
[0069] At step 910, in response to a loss of focus or 
a pressing of the Enter key, through the socket connec- 
tion established for agent session interface 800A dis- 
played on terminal 104N, the (administration) Master 
Applet at terminal 1 04N sends a command to WTS serv- 
. er 144, to retrieve the information in participant list 1, 
URL history list 1 , and data list 1 (see figure 6) for the 
Agent Applet. 

[0070] At step 912, WTS server 144 sends the infor- 
mation requested to the Agent Applet (via the Master 
Applet). 

[0071] Atstep914,the Agent Applet at terminal 104N 
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displays some information from participant list 1 and 
URL history list 1 in (participant) scrollable list box 816 
and (URL history) scrollable list box 818, respectively. 
[0072] At step 91 6, the agent selects join button 806 
in agent session interface 800A displayed on terminal 
104N. 

[0073] At step 91 8, in response to the selection at step 
916, through the socket connection which has been es- 
tablished for agent session interface displayed on ter- 
minal 104N, the (administration) Master Applet sends 
WTS server 144 a command to join the selected ses- 
sion. Based on the identification associated with the 
socket connection, WTS server is able to generate a 
ParticipantID for browser 114N and to find the Partici- 
pantAddress for terminal 104N. 
[0074] At step 920, WTS server 144 stores the Par- 
ticipantID and ParticipantAddress into participant list 1. 
At this step, participant list 1 includes two participant 
records (two rows) containing the PaticipantlDs for 
browsers 114A and 114N respectively. 
[0075] At step 922, at terminal 104N, the agent se- 
lects: leading check box 81 0-or following check box 81 2, 
or both of them. By only selecting leader check box B1 0, 
the activities at terminal 104N are synchronized at ter- 
minal 1 04A t but not other way around. By only selecting 
follower check box 812, the activities at terminal 104A 
are synchronized at terminal 104N, but not other way 
around. By selecting both leader and follower check 
boxes 810 and 812, the activities at terminals 104Aand 
1 04N are synchronized with each other (bi-directional 
synchronization). In response to the selection(s), 
through the socket connection which has been estab- 
lished for agent session interface 800A, the (adminis- 
tration) Master Applet sends WTS server 144 a com- 
mand designating the synchronization direction. WTS 
server 1 44 stores the synchronization direction informa- 
tion into the Direction fields of the two records in partic- 
ipation list 1 . In this example, it is assumed that the bi- 
directional synchronization has been selected for termi- 
nals 104A and 104N. 

[0076] At step 924, WTS server 144 sends the (ad- 
ministration) Master Applet the URL of the web page be- 
ing currently browsed at terminal 104A. 
[0077] At step 926, the Agent Applet at terminal 1 04N 
opens a browser window 1004 (a second browser in- 
stance) as shown in figure 10. 

[0078] At step 928, browser 1 1 4N downloads the web 
page identified by the URL from consumer page repos- 
itory 146, and displays it in browser window 1004. A 
(consumer) Master Applet, a set of DTS Applets, and a 
SessionlD Applet are embedded in the web page down- 
loaded. 

[0079] At step 930, browser 114N downloads (con- 
sumer) Master Applet 124N, set of DTS Applets 126N, 
and SessionlD Applet 128N. 

[0080] At step 932, the web pages displayed in sec- 
ond browser window 1004 at terminal 104N are being 
synchronized with the web pages being displayed at ter- 



minal 104A. 

[0081] After step 932, if the agent (the first agent) at 
terminal 104N needs assistance from another agent 
(the second agent) at terminal 104K, the first agent can 

s call the second agent and tell him/her the current ses- 
sion ID. The second agent can then join the current ses- 
sion using an agent session interface as shown in figure 
8A displayed at terminal 104K. 
" [0082] Referring to figure 1 0, there is shown a screen 

to display containing two browser instances (800 A and 
1004) at terminal 104N, in accordance with the present 
invention. 

[0083] As shown in figure 10, at terminal 104N, the 
first browser instance provides an agent session inter- 
ns face 800 A to control and monitor the current session, 
and the (administration) Master Applet for agent session 
interface 800A establishes and maintains a socket con- 
nection for agent session interface 800A. The second 
browser instance provides a browser window 1004 to 
20 display the web pages being synchronized. (Consumer) 
Master Applet 1 24N establishes and maintains a socket 
connection for each web page displayed in browser win- 
dow 1004. 

[0084] Referring to figure 11, there is shown a flow- 
25 chart illustrating the operation of .web page synchroni- 
zation, in accordance with the present invention. 
[0085] In the example shown in figure 11, it is as- 
sumed that: (l)aconsumeratterminal 104A is browsing 
web pages from consumer page repository 146 via 
so browser 1 1 4A, (2) a session has been created for brows- 
er 114A, (3) session list 1 and participant list 1 shown in 
figure 6 have been created for the session, (4) bi-direc- 
tional synchronization has been selected for terminal 
104A and all participant terminals, and (5} the (consum- 
es er) Master Applet, DTS Applets, and SessionlD Applet 
have been downloaded into browser 104A and all par- 
ticipant browsers. 

[0086] As shown in figure 11, at step 1104, browser 
114A loads a web page either from consumer page re- 

40 pository 146 or from memory area 115A in terminal 
104A. If Master Applet 124A, DTS Applets 126A, and 
SessionlD Applet 128A had not been download to 
browser 11 4A, browser 1 1 4A would download these Ap- 
plets from consumer page repository 146. However, in 

45 this example, these Applets are assumed to be down- 
loaded. 

[0087] At step 1 1 06, in response to the loading of the 
web page, browser 114A initializes and invokes Master 
Applet 124A, DTS Applets 126A, and SessionlD Applet 
50 128 A. 

[0088] At step 1108, Master Applet 1 24A: (1) opens a 
dedicated socket, and establishes a socket connection 
to WTS gateway 142 for browser 114A and the web 
page loaded, and (2) via the socket connection, sends 
55 WTS server 1 44 a command together with an ID unique 
to browser 114A and the URL of the web page loaded. 
Based on the unique ID, WTS server is able to identify 
the session created for browser 114A. 
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[0089] At step 1110, WTS server 144 identifies the 
session for browser 114A. 

[0090] At step 1112, WTS server 1 44 locates all IP ad- 
dresses assigned to participant terminals in participant 
list 1 (shown in figure 6), and sends a command, togeth- 
er with the URL, to all the participant terminals (except 
that WTS server 144 does not sent the URL to terminal 
104A, because the URL is originated from terminal 
104 A). 

[0091] At step 1114, upon receiving the command, the 
(consumer) Master Applets in the participant terminals 
initialize themselves and pass the URL to their respec- 
tive browsers. 

[0092] At step 1116, the respective browsers in the 
participant terminals download and display the web 
page according to the URL. 

[0093] It should be noted that, like terminal 104A, 
each of the participant terminals (at which agent session 
interface is displayed) can lead the page synchroniza- 
tion using the operation shown in figure 11. 
[0094] Referring to figure 1 2A, there is shown a web 
page containing five data fields, specifically: name 
1202, time period 1204, account balance 1206, pay- 
ment 1 208, comments 1 21 0, a text box 1 21 2 for display- 
ing the current session ID, and a text box for displaying 
the call center number the consumer can call, in accord- 
ance with the present invention. 
[0095] Referring to figure 12B, there is shown a web 
page that is similar to that of figure 1 2A, except that the 
data in the field of name 202 is changed from Susan 
King to Sue Grant and the changes are synchronized at 
a participant terminal, in accordance with the present 
invention. 

[0096] Referring to figure 13, there is shown a flow- 
chart illustrating the operation of data synchronization, 
in accordance with the present invention. 
[0097] In the example shown in figure 13, it is as- 
sumed that: (1 ) a customer at terminal 1 04A is browsing 
web pages via browser 114A, (2) a session has been 
created for terminal 104A, (3) session list 1 and partici- 
pant list 1 shown in figure 6 has been created for the 
session, (4) terminal 104N is one of the participants, (5) 
web page 1200 containing five data fields shown in fig- 
ure 12A is displayed on terminals 104A and all partici- 
pant terminals, (6) a bi-directional synchronization has 
been selected for terminal 104A and all participant ter- 
minals, (7) the (consumer) Master Applet, DTS Applets, 
and SessionID Applet have been downloaded to brows- 
er 1 1 4A and the browsers at all participant terminals, (8) 
the DTS Applets contains five individual Applets: DTS 
Applet! , DTS Applet 2 , DTS Applet 3 , DTS Applets 4 , and 
DTS Applet 5 , (9) these five individual DTS Applets are 
respectively responsible for monitoring and processing 
the events occurred on the five data fields of web page 
1200 shown in figure 12A, (10) (consumer) Master Ap- 
plet 124A has established a dedicated socket connec- 
tion to WTS gateway 142 for web page 12A displayed 
at terminal 1 04A, and (1 1 ) the customer at terminal 1 04A 



wants to make changes to name field 1 202 from Susan 
King to Sue Grant. 

[0098] As shown in figure 13, at step 1304, the cus- 
tomer changes the name in name field 1 202 from Susan 
5 King to Sue Grant. 

[0099] At step 1 306, in response to a loss of focus on 
name field 1202 or pressing the Enter key, DTS Applet-, 
detects the change and passes the change to Master 
Applet 124A. 

io [0100] At step 1308, via the dedicated socket connec- 
tion, Master Applet 1 24A sends WTS server 1 44 a com- 
mand together with the change of name field 1202. 
Since this change is passed to WTS server 144 via the 
dedicated socket connection established for web page 

15 1200, WTS server 144 is able to recognize the origin of 
the command, web page 1 200, and the name field upon 
which the change was made. 

[0101] At step 1310, WTS server 144 identifies the 
session created for browser 114A. 

20 [0102] At step 1312, WTS server 144 locates the IP 
addresses assigned to participant browsers in partici- 
pant list 1 and sends a command (together with the 
change of name field 1202) to the Master Applets in all 
participant terminals (except that WTS server 144 does 

25 not send the command and change to browser 114A, 
since this change originated from browser 114A). 
[0103] At step 1314, upon receiving the command, 
the (consumer) Master Applets (including Master Ap- 
plets 1 24N) pass the change of name field 1 200 to their 

30 respective DTS Applets, including the DTS Appte^ at 
browser 114N. 

[0104] At step 1 316, the DTS Apple^ display the up- 
date "Susan Grant" into the name fields on respective 
web page 1200 displayed on the respective terminals, 
35 including terminal 104N. 

[0105] It should be noted that the operation shown in 
figure 13 can be used to perform data synchronization 
for the other four data fields on web page 1200 shown 
in figure 1 2A. 

40 [0106] It should also be noted that the data field syn- 
chronization can also be performed at terminar 104N. 
For example, as shown in figure 12B, when the agent 
at terminal 104N enters comments of "Account's name 
had been changed" to comments field 1210' on web 

45 page 1200", this updates will be displayed in comments 
field 1210 at terminal 104A, by using the operation 
shown in figure 13. 

[0107] Referring to figure 14, there is shown a flow- 
chart illustrating the operation of web page tracking, in 

50 accordance with the present invention. 

[0108] In the example shown in figure 14, it is as- 
sumed that: (1) a customer at terminal 104A is browsing 
web pages via browser 114A, (2) a session has been 
created for terminal 104A and all participant terminals, 

55 (3) session list 1, participant list 1, and URL history list 
1 shown in figure 6 have been created for the session, 
(4) bi-directional synchronization has been selected for 
terminal 104A and all participant terminals, and (5) the 
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(consumer) Master Applet, DTS Applets, and SessionID 
Applet have been downloaded into terminals 104A and 
all participant terminals. 

[0109] As shown in figure 14, at step 1404, browser 
1 1 4A downloads a web page from either the consumer 
page repository 146 or memory area 115A of terminal 
104 A If Master Applet 124A, DTS Applets 126A, and 
SessionID Applet 128A had not been download to ter- 
minal 104A, browser 114A would download them from 
HTTP server 152. However, in this example, these Ap- 
plets have been downloaded. 

[0110] At step 1406, web browser 114A initializes and 
invokes Master Applet 124A, DTS Applets 126A, and 
SessionID Applet 128A. 

[01 1 1 ] At step 1 408, Master Applet 1 24A opens a ded- 
icated socket and establishes a socket connection to 
WTS gateway 1 42 for web browser 114A and the web 
page loaded. Master Applet 1 24A then sends WTS serv- 
er 144 a command, together with: (1) an ID unique to 
browser 1 1 4A, and (2) the URL of the web page loaded. 
When commands and URL are delivered through this 
socket connection, WTS server 144 is able to recognize 
the origin of the commands and URL. 
[0112] At step 1410, WTS server 144 identifies the 
session ID for browser 11 4A. 

[01 1 3] At step 1 41 2, WTS server 1 44 locates the ses- 
sion list 1 and URL history list 1 . 
[0114] At step 1414, WTS server 144 issues a time 
stamp (loading time) for indicating the time at which the 
command was received, and stores the URL and time 
stamp to URL history list 1 . 

[01 1 5] At step 1 41 6, browser 1 1 4A sends WTS server 
144 a request to load a subsequent web page. 
[0116] At step 1418, before loading the subsequent 
web page, via the socket connection, Master Applet 
1 24A sends WTS server 1 44 a command, together with 
the URL, to inform WTS server 144 that the current web 
page has been unloaded. 

[0117] At step 1420, WTS server 144 identifies the 
session for terminal 104A. 

[0118] At step 1 422, WTS server 1 44 locates the ses- 
sion list 1 and URL history list 1 . 
[0119] At step 1424, WTS server 144 issues a time 
stamp (unloading time) for indicating the time at which 
the command was received, and stores the URL and 
time stamp to URL history list 1 . 
[01 20] At step 1 426, Master Applet 1 24A disconnects 
the socket connection for the web page that has been 
unloaded. 

[0121] Referring to figure 15, there is shown a flow- 
chart illustrating the operation of data tracking, in ac- 
cordance with the present invention. 
[0122] In the example shown in figure 15, it is as- 
sumed that: (1 ) a customer at terminal 1 04A is browsing 
web pages via browser 114A, (2) a session has been 
created for terminal 104A, (3) session list 1 and partici- 
pant list 1 shown in figure 6 has been created for the 
session, (4) terminal 104N is one of the participants, (5) 



web page 1200 containing five data fields shown in fig- 
ure 12A is displayed on terminals 104A and all partici- 
pant terminals, (6) a bi-directional synchronization has 
been selected for terminal 104A and all participant ter- 

5 minals, (7) the (consumer) Master Applet, DTS Applets, 
and SessionID Applet are downloaded to terminal 104A 
and all participant terminals, (8) the DTS Applets con- 
tains five individual Applets: DTS Applet,, DTS Applet 2 , 
DTS Applet 3 , DTS Applets 4 , and DTS Applet 5 , (9) these 

10 five individual DTS Applets are respectively responsible 
for displaying, monitoring and processing the events oc- 
curred on the five data fields of web page 1200 shown 
in figure 12A, (10)* Master Applet 124A has established 
a dedicated socket connection to WTS server 144 for 

is web page 1200 displayed on terminal 104A, and (11) 
the customer at terminal 104A wants to make changes 
* to name field 1202 from Susan King to Sue Grant. 
[0123] As shown in figure 15, at step 1504, the cus- 
tomer changes the name in name field 1 502 from Susan 

20 King to Sue Grant. 

[0124] At step 1 506, in response to a loss of focus on 
name field 1202 or pressing the Enter key, DTS Apple^ 
detects the change and passes the change to Master 
Applet 124A. 

25 [01 25] At step 1 508, via the dedicated socket connec- 
tion, Master Applet 124A sends WTS server 144 a com- 
mand together with the change of name field 1202. 
Since this change is passed to WTS server 144 via the 
dedicated socket connection established for web page 

30 1 200, WTS server 1 44 is able to recognize the origin of 
the command, web page 1 200, and the name field upon 
which the change was made. 

[0126] At step 1510, WTS server 144 identifies the 
session created for terminal 104A. 

35 [0127] At step 1512, WTS server 144 stores the URL 
and update of name field 1 202 into data list 1 . 
[0128] It should be noted that the operation shown in 
figure 1 5 can be used to perform data tracking for the 
other four data fields on web page 1200, and to perform 

40 data tracking for all participant terminals. 

[0129] Referring to figure 16, there is shown a flow- 
chart illustrating the operation of joining a session by a 
supervisor, in accordance with the present invention. In 
the example shown in figure 16, it is assumed that the 

45 supervisor is on duty at terminal 104K in a call center. 
[01 30] As shown in figure 1 6, at step 1 604, the super- 
visor performs the steps shown in figure 7, where the 
supervisor downloads a supervisor.page on which a (ad- 
ministration) Master Applet (referred as Master-Applet,) 

50 and a Supervisor Applet are imbedded. The Supervisor 
Applet displays a supervisor session interface (as 
- shown in figure 8B) in a first browser instance (see 800E3 
in figure 17) on terminal 104K. Master- Applet-, maintains 
a dedicated socket connection to WTS gateway 142 for 

55 the first browser instance (see 800B shown in figure 1 7). 
[0131] At step 1606, from the first browser instance 
(see 800B shown in figure 17), the supervisor selects a 
session ID (listed in text box 832) and then select ses- 
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sion button 838. 

[01 32] At step 1 608, in response to the selection of 
the select session button 838, browser 1 1 4K downloads 
a supervisor agent page, on which a (administration) 
Master Applet (referred as Master-Applet 2 ) and an 
Agent Applet are embedded. The Agent Applet creates 
a supervisor agent session interface 800C (as shown in 
figure 8C) and displays it in a second browser instance 
(see 800C in figure 17) on terminal 104K. Master- 
Applet 2 opens and maintains a dedicated socket con- 
nection to WTS gateway 142 for the second browser in- 
stance (see supervisor agent session interface 800C 
shown in figure 17). 

[0133] At step 1610, there can be two possible sce- 
narios. A first scenario is that: an agent has joined the 
selected session to help the consumer, and the super- 
visor wants to join the selected session as a participant. 
Under this scenario, the supervisor simply selects join 
button 846, and leader and follower buttons 850 and 852 
are both selected automatically. A second scenario is 
that: no agent has joined the session and the supervisor 
wants to join the session. Under this scenario, the su- 
pervisor joins the session just like an agent, by first se- 
lecting leader button 850and/or follower button 852, and 
then join session button 846. In this example, it is as- 
sumed that a consumer at terminal 104A and an agent 
at terminal 104N have joined the session, and the su- 
pervisor wants to join the selected session. 
[0134] At step 1612, the supervisor selects join ses- 
sion button 846. 

[0135] At step 1614, via the socket connection for the 
second browser instance (see supervisor agent session 
interface 800C shown in figure 17), the Master-Appiet 2 
sends WTS server 144 a command together with the 
selected session ID for the selected session. 
[0136] At step 1615, WTS serer 144 locates the ses- 
sion indicated by the selected session ID, and sends in- 
formation stored in participant list 1 and URL history list 
1 (see figure 6) to Master- Applet^ 
[0137] At step 1616, WTS server 144 stores Partici- 
pant! D and Participant Address into participant list 1 for 
browser 114K. At this step, participant list 1 includes 
three participant records (three rows) for browsers 
114A, 114K, and 114N respectively. 
[0138] At step 1618, Agent Applet at terminal 104K 
displays the information stored in participant list 1 , and 
URL history list 1 in participant text box 856, and URL 
history text box 858 (see figure 8C) respectively. 
[0139] At step 1620, WTS server 144 sends Master- 
Apple^ the URL of the web page being currently dis- 
played at terminals 104A and 104N. 
[0140] At step 1622, the Agent Applet at terminal 
104K opens a third browser instance (see 1704 in figure 
17). 

[0141] At step 1624, browser 114K downloads the 
web page identified by the URL from consumer page 
repository 146 (or loads the web page from memory ar- 
ea 11 5K in terminal 104K if it is cached there), and dis- 



plays it in the third browser instance (see 1704 in figure 
17). 

[0142] At step 1626, browser 114K downloads (con- 
sumer) Master Applet 124K, DTS Applets 126K, and 
5 SessionID Applet 128 from consumer page repository 
1 46 according to the applet tags in the current web page 
(assuming that these Applets have not previously down- 
loaded). 

[0143] At step 1628, Master Applet 124K opens a 
10 dedicated socket and establishes a socket connection 
to WTS gateway 1 42 for the third browser instance 1 704 
shown in figure 17. 

[0144] After step 1630, the web pages displayed in 
third browser instance 1704 at terminal 104K are being 
is synchronized with the web pages being displayed at ter- 
minals 104 A and 104N. 

[0145] Referring to figure 17, there is shown three 
browser instances (800B, 800C, and 1704) for the su- 
pervisor in response to the steps shown in figure 16, in 

20 accordance with the present invention. 

[0146] Referring to figure 18, there is shown a flow- 
chart illustrating the operation of re-browsing a web 
page previously reviewed in a session, in accordance 
with the present invention, 

25 [0147] In the example shown in figure 18, it is as- 
sumedthat: (1 ) a consumer at terminal 104A is browsing 
web pages from consumer page repository 146 via 
browser 114A, (2) a session list 1 shown in figure 6 has 
been created for browser 114A, (3) an agent (or a su- 

30 pervisor>is on duty at terminal 104N in a call center, and 
agent class (or supervisor class) has been assigned to 
browser 104N, (4) at browser 114N, the first and second 
browser instances for the agent as shown in figure 10 
(or the first, second and third browser instances for the 

35 supervisor as shown in figure 17) have been displayed, 
(5) via their respective socket connections established 
by their Master Applets, the first and second browser 
instances for the agent as shown in figure 10 (or the first, 
second and third browser instances for the supervisor 

40 as shown in figure 17) have been connected to WTS 
gateway 142, (6) Master Applets (124Aand 124N), DTS 
Applets (126Aand 126N) and SessionID Applets (128A 
and 12BN) have been downloaded into terminals 104A 
and104N respectively, (7) the agent (or supervisor)- has 

45 selected and joined the session created for browser 
1 1 4A, (8) at browser 1 1 4N, the second browser instance 
for the agent as shown in figure 10 (or the third browser 
instance for the supervisor as shown in figure 17) is be- 
ing synchronized with browser 1 1 4A, and (9) bi-direction 

50 synchronization has been selected for browsers 11 4A 
and 114N. 

[0148] At step 1802, for an agent user, via scrollable 
list box 818 on agent session interface shown in figure 
10, he/she reviews the URLs for ail the web pages pre- 
ss viously browsed by browser 114A in the selected ses- 
sion. For a supervisor, via scrollable list box 858 on su- 
pervisor session interface shown in figure 17, he/she re- 
views the URLs for ail the web pages previously 
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browsed by browser 114A in the selected session. 
[01 49] At step 1 804, to display an individual web page 
previously browsed by browser 11 4A, the agent (or su- 
pervisor) selects a URL from scrollable list box 818 (or 
scrollable list box 858) and double-clicks on it. 5 
[0150] At step 1806, for the agent, the (agent) Master 
Applet or (the supervisor Master Applet) sends WTS 
server 144 a command together with the selected URL, 
via its respective socket connection. 
[0151] At 180B, WTS server 144 sends a command io 
together with the URL and the time information (loading 
and unloading) to Master Applets 124A and 124N, so 
that Master Applets 1 24A and 1 24N can inform their re- 
spective browsers 114A and 114N to load and display 
the web page based on the URL 15 
[0152] At 1810, WTS server 144 checks whether 
browser 114A previously performed any activities to da- 
ta fields on the web page identified by the URL, based 
on the information stored in URL history list 1 and data 
list 1. As shown in figure 6, URL history 1 contains the 20 
information about: (a) participant ID of browser 114A, 
(b) the URL, and (c) the loading and unloading time of 
the web page identified by the URL Data list 1 contains 
the information about: (a) data field names for data 
fields, (b) value of the data fields, and (c>the times at 25 
which values of the data fields were changed. 
[0153] At step 1812, if browser 114 previously per- 
formed any activities to the data fields on the web page 
identified by the URL, WTS server 144 sends a com- 
mand (together with the data field names, values of the 
data fields, and time information) to Master Applet 1 24A 
(at browser 114A) and Master Applet 124N (at browser 
114N). 

[0154] At step 1814, at browser 114A, Master Applet 
1 24A passes the command, data field names, and data 
field values to DST Applets 126A, so that DTS Applets 
124 A can display the data field values into respective 
data fields on the web page being displayed. At browser 
114N, Master Applet 124N passes the command, data 
field names, and data field values to DST Applets 1 26N, 
so that DTS Applets 1 24N can display the data field val- 
ues into respective data fields on the web page being 
displayed. 

[0155] Since the loading time and unloading time of 
the URL and the setting time for a data field are recorded 
in URL history list 1 and data list 1 , if desired, the web 
page identified by the URL and the activities performed 
to the data fields can be duplicated (loading the web 
page, setting data fields on the web page, and unloading 
the web page) according to the time information. 
[0156] Referring to figure 19, there is shown a flow- 
chart illustrating the operation of re-browsing all web 
pages previously reviewed in a session, in accordance 
with the present invention. 

[0157] In the example shown in figure 19, it is as- 
sumed that: (1 ) a consumer at terminal 1 04A is browsing 
web pages from consumer page repository 146 via 
browser 114A, (2) a session list 1 shown in figure 6 has 



been created for browser 114A, (3) an agent (or a su- 
pervisor) is on duty at terminal 1 04N in a call center, and 
agent class (or supervisor class) has been assigned to 
browser 104N, (4) at browser 114N, the first and second 
browser instances for the agent as shown in figure 10 
(or the first, second and third browser instances for the 
supervisor as shown in figure 17) have been displayed, 
(5) via their respective socket connections established 
by their respective Master Applets, the first and second 
browser instances for the agent as shown in figure 10 
(or the first, second and third browser instances for the 
supervisor as shown in figure* 17) have been connected 
to WTS gateway 142, (6) Master Applets (124A and 
124N), DTS Applets (126A and 126N) and SessionID . 
Applets (128A and 128N) have been downloaded into 
terminals 104Aand 104N respectively, (7) the agent (or 
supervisor) has selected and joined the session created 
for browser 114A, (8) at browser 114N, the second 
browser instance for the agent as shown in figure 1 0 (or 
the third browser instance for the supervisor as shown 
in figure 17) is being synchronized with browser 114A, 
and (9) bi-direction synchronization has been selected 
for browsers 1 1 4A and 1 1 4N. 

[0158] At step 1902, for an agent user, via scrollable 
list box 818 on agent session interface shown in figure 
10, he/she reviews the URLs for all the web pages pre- 
viously browsed by browser 114A in the selected ses- 
sion. For a supervisor, via scrollable list box 858 on su- 
pervisor session interface shown in figure 1 7, he/she re- 
views the URLs for all the web pages previously 
browsed by browser 114A in the selected session. 
[0159] At step 1904, to display all web pages previ- 
ously browsed by browser 114A, the agent (or supervi- 
sor) selects Go to URLs button 820 in the agent session 
interlace as shown in figure 10 (or Go to URLs button 
860 in the supervisor session interface as shown in fig- 
ure 17. 

[0160] At step 1 906, the (agent) Master Applet, or the 
(supervisor) Master Applet, sends a command to WTS 
server 144. 

[0161] At 1908, WTS server 144 sequentially sends 
commands, together the URLs and time information, to 
Master Applets 1 24A and 1 24N, so that Master Applets 
124A and 124N can inform their respective browsers 
1 1 4A and 1 1 4N to load and display the web pages based 
on the URLs. 

[0162] At 1910, for each one of URLs that are sent 
together with the commands, WTS server 144 checks 
whether browser 114A previously performed any activ- 
ities to data fields on a web page identified by a respec- 
tive URL, based on the information stored in URL history 
list 1 and data list 1 . 

[0163] At step 1912, if browser 114 previously per- 
formed any activities to the data fields on the web page 
identified by a respective URL, WTS server 144 sends 
a command (together with the data field names and val- 
ues of the data fields) to Master Applets 1 24A (at brows- 
er 114A) and Master Applet 124N (at browser 114N). 
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[0164] At step 1914, at browser 114A, Master Applet 
124A passes the command, data field names, and data 
field values to DST Applets 126A, so that DTS Applets 
124A can display the data field values into respective 
data fields on the web page being currently displayed. 
At browser 114N, Master Applet 124N passes the com- 
mand, data field names, and data field values to DST 
Applets 126N, so that DTS Applets 124N can display 
the data field values into respective data fields on the 
web page being currently displayed. 
[0165] Since the loading time and unloading time of 
the URLs and the setting time for data fields are record- 
ed in URL history list 1 and data list 1 , if desired, all the 
web pages identified by the URLs and the activities per- 
formed to the data fields can be duplicated (loading the 
web page, setting data fields on the web page, and un- 
loading the web page) according to the timing informa- 
tion. 

[01 66] It shou Id be noted that, in the above-described 
embodiments, all the Applets (Master Applets, DTS Ap- 
plets, SessionID Applets, and Agent Applety embedded 
into web pages are written using Java. However, some 
or all of these Applets can be written using a browser 
script language, such as Java Script More specifically, 
the codes for these Applets can be selectively written 
into web pages using the browser script language, in- 
stead of using applet tags to link these Applets. When 
a web browser downloads a web page containing the 
Applets written in browser script language, it stores 
these Applets into the memory area of the terminal on 
which the web browser is running, and then initializes 
and invokes them. 

[01 67] The present invention has the following advan- 
tages: 

[0168] Dependable web page tracking and synchro- 
nizing - It tracks and synchronizes all user activities, 
even if web pages come from cached pages stored in 
browser cache or proxy servers. 
[0169] Ease of use - It eliminates the current manual 
process of multiple users separately re-creating the web 
navigation. 

[0170] Ease of execution (from users' point of view) - 
It does not require additional software to support the 
present invention. No software needs to be installed, 
configured, or run by a user. 

[0171] Portability - It works across different operating 
systems at both client and server sides. On the client 
side, the requirement is that there be a web browser that 
supports Java Applets. On the server side, the require- 
ment is that there be a Java Virtual Machine (JVM) on 
the same server that provides the HTTP service. Since 
there are JVMs practically for every operating system, 
the server components of the present invention have the 
potential to run on all the operating systems. 
[01 72] Compatibility - It works together with any HTTP 
servers from different vendors because the server com- 
ponents of the present invention requires no processing 
by HTTP servers, and thus are independent from HTTP 



servers. 

[0173] Flexibility - Web page synchronization can be 
used independently in conjunction with web page track- 
ing. Web page synchronization does not require persist- 

s ent storage of any of the data tracked 

[0174] User privacy - It ensures a reasonable level of 
user privacy, since tracking and synchronization is lim- 
ited to pages served by a web site that the information 
provider has control over. 

io [0175] Multiple HTTP server supported- It can handle 
the situation where a company has multiple physical 
servers running its web site, since the separation of the 
WTS gateway and server components enables a gate- 
way to be placed on each HTTP server -- each commu- 

is nicating with a common WTS server. 

[0176] While the. invention has been illustrated and 
described in detail in the drawing and foregoing descrip- 
tion, it should be understood that the invention may be 
implemented through alternative embodiments within 

20 the spirit of the present invention. Thus, the scope of the 
invention is not intended to be limited to the illustration 
and description in this specification, but is to be defined 
by the appended claims. 

25 

Claims 

1 . A method. for managing activities performed to pag- 
es [204,214,224...] at a terminal [104A] and activi- 
30 ties between said terminal and a further terminal 
[104K, 104N], the pages being retrieved from a net- 
work site [134], characterised by the method com- 
prising the steps of: 

3S (a) at said terminal retrieving pages; 

t (b) at said terminal performing activities [11 4A, 
115A] to said pages retrieved; 
(c) at the network site recording [148} said ac- 
tivities for said terminal; 

40 (d) at the further terminal establishing contact 

with said terminal; and 

(e) at the further terminal displaying [Fig. 6] ac- 
tivities recorded for said terminal. 

45 2. The method of Claim 1 further characterised by 
managing page synchronization and by the step of : 

(f) between said terminal and the further termi- 
nal synchronising activities performed either at 

50 said terminal or said further terminal. 

3. The method of Claim 2 further characterised by in 
step (b) said activities including at least one of load- 
ing a page, unloading a page and changing a data 

55 field on a page [Fig. 12A, Fig. 12B]. 

4. A method according to any one of Claims 1 to 3 for 
tracking activities with pages [204,214,224...] re- 
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quested for loading over a network [1 29] by retrieval 
from a page server [1 52,146] at a network site [1 34] 
to an individual terminal [104A...104K...104N] char- 
acterised by sending information about the activi- 
ties to a page tracking server [144] and comprising 
the steps of: 

(g) loading a first page [204] from the page 
server, the page being associated with a page 
locator for indicating a location of the page in 
the server, and the page containing program in- 
formation [208,218,228...] of at least location 
information for indicating a program; 

(h) loading the program [124A...124K...124N] 
[1 26A. . . 1 26K. . . 1 26N] [1 28A. . . 1 28K. . . 1 28N] 
from the server based on the location informa- 
tion, and executing the program; 

(j) the program monitoring [114A,115A...114K, 
1 1 5K.. . 1 1 4N, 1 1 5N] activities with the page; and 
(k) the program sending [7] information [Fig.6] 
about the monitored activities to the page track- 
ing server to be available for storage therein. 

5. The method of claim 4 further characterised by the 
step of providing said program information as the 
program. 

6. The method of claim 4 further characterised by the 
page locator being URL (Uniform Resource Loca- 
tor), and the program information being a tag. 

7. The method of claim 4 further characterised by the 
page server being part of a web site [1 34 ]. 

8. The method of claim 4 further characterised by the 
steps of: 

(1) loading a second page [21 4] from the page 
server, the second page being associated with 
a page locator for indicating a location of the 
second page in the page server, the second 
page containing location information for indi- 
cating a location of the program loaded in step 
(h); 

(m) executing the program based on the loca- 
tion information in the second page; 
(n) the program monitoring activities with the 
second page; and 

(p) the program sending the information about 
the activities with the second page to the page 
tracking server. 

9. The method of any one of Claims 1 to 8 further char- 
acterised by managing said activities by the steps 
of: 

(q) creating a session for the terminal in re- 
sponse to an initial said request; 



(r) receiving subsequent requests from said ter- 
minal for pages; and 

(s) storing activity monitoring information into 
said session. 

5 

10. The method of claim 9 further characterised by set- 
ting a session interval for said session, maintaining 
said session created for the terminal, if within said 
session interval: (i> at least one activity is performed 

io to a page, or (ii) a new request is receives for re- 
trieving a page; and purging said session in the ab- 
sence of such activity or request within said interval. 

11. The method of Claims 9 or 10 further characterised 
by responding to request from a further terminal to 
join said session, displaying at the further terminal 
session activities stored according to step (s> syn- 
chronizing subsequent activities between said ter- 
minal and said further terminal and storing said sub- 

20 sequent activities into said session. 

1 2. The method of Claims 1 0 or 1 1 further characterised 
by extension to a plurality of terminals including the 
said terminal and by creating a respective session 

25 for each of the plurality of terminals and storing ac- 
tivity monitoring information for each said terminal 
into said respective session. 

1 3. The method of Claim 1 2 further characterised by re- 
30 ceiving a request from an administrative terminal 

[1 04K] among said plurality of terminals to select for 
one of said plurality of said terminals the respective 
session, displaying said stored respective activities 
and synchronizing subsequent activities between 
35 said administrative terminal and the terminal having 
said selected session and storing said subsequent 
activities into said respective session. 

14. The method of any one of Claims 1 to 13 further 
40 characterised by synch ronizinga.specific page at a 

first and a second terminal on the first terminal re- 
questing the specific page by the program at the first 
terminal sending the specific page iocator to the 
second terminal in response to the loading of the 
45 first page. 

15. The method of Claim 14 further characterised by 
sending the page locator via a page synchroniza- 
tion server. 

50 

1 6. A terminal lor the method of any one of Claims 1 to 
15. 

17. A network operated according to a method of any 
55 t one of Claims 1 to 15. 
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